In 2020 I became a first-time tech lead on the largest team I ever worked in, including six engineers. At the time opinions, personalities and cultures varied widely. Half the team was working in Eastern Europe (GMT+2), and the other half was in Japan (GMT+9). One of my biggest challenges in those days was how to bring all the engineers on the team together to work as a single unit. There were disagreements on all levels of implementation details, branch management strategies, communication strategies, release/deploy strategies, and basically everything. Sometimes we purposefully implemented random things without oversight from our product manager, due to a lack of knowledge of who our users actually were and how we understood their needs.

It would have been impossible for me to write a guide on every aspect of decision-making for every possible domain related to engineering. Life is not a finite state machine; there is no playbook big enough that will guide you through it step by step. This is where first principles shine.

Picture engineering as a tree of infinite depth and breadth. Each node represents a decision we have to make that can be split into an unknown number of branches. Traversing this tree is our day-to-day work. When we first start our careers, the shape and scope of this tree are largely unknown. But as we mature, we gain efficiency at pattern-matching our current location in the tree to repeated patterns we saw at a previous branch in our traversal. With experience more branches and possible decisions become immediately visible, and in turn our traversal through these branches quickens. "Should this be a hot fix? Should I be pedantic here? Is this a release blocker? Am I correctly prioritizing my tasks? Should I use the X pattern over Y here? What is the correct path to take?", we wonder. It is this decision-making process that can be guided by a set of first principles that are applicable not just to a certain set of particulars, but to any decision in any domain.

The natural course is to proceed from what is clearer and more knowable to us, to what is more knowable and clear by nature; for the two are not the same. Hence, we must start with things which are less clear by nature, but clearer to us, and move on to things which are by nature clearer and more knowable. The things which are in the first instance clear and plain to us are rather those which are compounded or indiscriminate or confused or jumbled up or mixed together.

It is only later through an analysis of these that we come to know the elements and principles. That is why we should proceed from the universal to the particular. It is the whole which is more knowable by perception, and the universal is a sort of whole: it embraces many things as parts

— Aristotle, Physics

Principle 1: Be the developer you want to work with

It is amazing what one can accomplish if one does not care who gets the credit.

— Harry Truman

The golden rule is at the heart of our engineering culture: "Treat others as you would like others to treat you." We believe in fostering an environment of vulnerability, trust, empathy, and accountability. By supporting each other's growth, celebrating collective achievements, and practicing egoless programming, we create a team that thrives on holding ourselves accountable for our mutual success. We recognize the importance of maintaining a healthy work-life balance and prioritize personal health to ensure sustained productivity and well-being. We view our coworkers as internal customers, valuing their unique perspectives and treating our interactions as meaningful relationships rather than business transactions. By prioritizing their needs and providing exceptional support, we strengthen our team and cultivate an environment that embraces collaboration and success.

Additional reading:

• Golden Rule

• The ten commandments of egoless programming

Principle 2: Practice a healthy skepticism

It is important not to worship what is known, but to question it.

— Jacob Bronowski

Embracing a healthy skepticism enables us to challenge the status quo and continuously question our understanding of problems and solutions. By acknowledging our cognitive biases and being open to alternative perspectives, we cultivate an environment of continuous learning and improvement. We encourage research, exploration, and exposure to diverse technologies, languages, industries, and cultures, seeking inspiration from external domains to solve local challenges.

Additional reading:

• Kruger effect

• List of cognitive biases

• Cartesian doubt

• Ted Talk: Unknown Unknowns by Dr. Ben Newling

Principle 3: As simple as possible, as complicated as necessary

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take.

— Antoine de Saint-Exupéry

We believe in the elegance of simplicity. Avoiding over-engineering for the sake of engineering, we strive to create solutions that are simple, maintainable, and fit for purpose. By adhering to the rule of least power, we resist the temptation to add unnecessary complexity. Our focus is on building efficient, scalable, and robust systems that solve real problems effectively.

Additional reading:

• What is negative code

• Rule of least power

• Cheng Lou: On the spectrum of abstraction

Principle 4: Iterate quickly

Better a diamond with a flaw than a pebble without.

— Confucius

Recognizing that perfection can be the enemy of progress, we embrace an iterative approach to development. We prioritize speed and agility, valuing the ability to adapt and iterate rapidly over excessive planning and premature optimization. We understand that delivering value to our customers requires setting achievable milestones, fostering a culture of experimentation, and embracing the philosophy of "better done than perfect." We iterate, learn, and refine our solutions based on feedback and real-world usage.

Additional reading:

• Your code may be elegant

• Perfect is the enemy of good

• You aren't gonna need it

• Efficiency–thoroughness trade-off principle

Principle 5: Engineering must serve the product and customer

If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.

— Albert Einstein

Our ultimate goal as engineers is to create value for our customers. We understand that software development is not an end in itself but a means to serve the needs of our users. We align our engineering efforts with the product vision and business goals by developing a deep empathy for our customers. We strive to understand the problems we are solving and focus on delivering solutions that truly meet the needs of our users.

Additional reading:

• Software engineering soft parts

• The joy of user-driven development